Complex integrated circuits, such as System-on-Chip designs, include a large number of circuitry blocks. As the term is used herein, “integrated circuit” includes devices such as those formed on monolithic semiconducting substrates, such as those formed of group IV materials like silicon or germanium, or group III-V compounds like gallium arsenide, or mixtures of such materials. The term includes all types of devices formed, such as memory and logic, and all designs of such devices, such as MOS and bipolar. The term also comprehends applications such as flat panel displays, solar cells, and charge coupled devices.
It is highly desirable to verify that such designs are complete and accurate, prior to committing the designs to silicon. The reasons for this are substantially obvious, and include items such as not wasting the time and the money required to manufacture tooling and then produce actual integrated circuits, only to discover that there is a flaw in the design that needs to be fixed.
The verification process currently consumes up to about seventy percent of the total development effort in modern, complex integrated circuit designs. Various verification systems are known in the art, such as eRM (Cadence/Specman), RVM (Synopsys/Vera), and VMM (System Verilog). The methods which are used today for stimulus generation are briefly described below.
Direct Signal/Pin Driving: This is the simplest and most straight forward method to drive design pins from the test case. This method is useful when the design has very few input pins and needs to drive very few combinations on it. This method fails when implementing complex design protocols, and is also inefficient when it comes to stimulus controllability, reusability, and simplicity of the test case.
Direct Bus Functional Module Control: In this method, the Bus Functional Module contains tasks and functions to drive the design ports per the protocol. The tasks and functions take the input data, which is used by the module to drive the design ports. The problem with this method is the tasks and functions of the module must be called repeatedly and in a specific order. As the verification scenario gets more complex, the tests therefore also become more complex. Reuse of the test cases in this method is almost nonexistent as one moves from device level verification to system level verification.
Transaction Level Control: In this method, the transaction class contains data, control, or other information that can be decoded by transactors and driven to the design ports as per the protocol. An atomic transaction generator is used to generate and send the transactions to the transactors. The atomic generator usually generates random transactions using only one transaction class, or it can get a transaction object from a test case or other sources to send directly to the transactors without any modification. This approach is commonly used in verification.
Scenario Level Control: In this method, a scenario generator is used along with the transaction level control to generate a sequence of transactions. The scenario generator randomizes an array of atomic transactions. Constraining of the items in the array is done to generate scenarios as needed. This approach has following issues. (1) The number of constraints to be coded and the complexity of method increases as one moves from a lower level to a higher level of test case abstraction. (2) Reusability of the constraints is difficult as one progresses from a lower level to a higher level of test case abstraction. (3) The tool requires more time and resources to resolve the constraints as the complexity and number of the constraints increases.
Verification engineers want to reuse device level test infrastructure at the system level, and generate complex test scenarios. Another desire for verification engineers is to manage reusability, controllability, and scalability of stimulus factors from the device level to the system level. However, the overall complexity of generating test scenarios tends to increase as the verification process progresses from device level to system level.
What is needed, therefore, is a staged scenario generation methodology for system on a chip verification to control, reuse, and scale scenario/transaction generation from device level verification to system level verification.